home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c++-part2 / 13079 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  3.1 KB
  1. Path: news.byu.edu!news
  2. From: "Stephen W. Liddle" <liddle@byu.edu>
  3. Newsgroups: comp.object,comp.lang.c++,comp.software-eng
  4. Subject: Re: Design language?
  5. Date: Fri, 22 Mar 1996 18:50:55 -0700
  6. Organization: Brigham Young University
  7. Message-ID: <315358FF.C79@byu.edu>
  8. References: <31437B51.27C3@bitmailer.net> <4i6qhq$4e8@gaia.ns.utk.edu> <4i9s82$4ps@Starbase.NeoSoft.COM> <314E0DD6.73F1@byu.edu> <4isdl7$ccu@Starbase.NeoSoft.COM>
  9. NNTP-Posting-Host: swliddle.byu.edu
  10. Mime-Version: 1.0
  11. Content-Type: text/plain; charset=us-ascii
  12. Content-Transfer-Encoding: 7bit
  13. X-Mailer: Mozilla 2.0GoldB2 (Win95; I)
  14.  
  15. Tim Dugan wrote:
  16. > 
  17. > In article <314E0DD6.73F1@byu.edu>, Stephen W. Liddle <liddle@byu.edu> wrote:
  18. > >Tim Dugan wrote:
  19. > >>
  20. > >> In article <4i6qhq$4e8@gaia.ns.utk.edu>,
  21. > >> Matt Kennel <kennel@msr.epm.ornl.gov> wrote:
  22. > >>
  23. > >> >I think the reality is that once some ideas and technology get settled
  24. > >> >and reliable enough to be automated, they end up--and should end up--in
  25. > >> >the ordinary language.   [...]
  26. > >>
  27. > >> [...] over time, we will add enough
  28. > >> formality and details to systems like the "unified method" to make
  29. > >> them executable and so they will generate complete code sets
  30. > >> where necessary.
  31. > >
  32. > >This is the direction I'd like to push things -- let the model contain
  33. > >the program.  In fact, I'd go so far as to hope that we could avoid
  34. > >"generating code" at all from the executable model.  (Eventually) we
  35. > >ought to be able to create efficient systems by compiling executable
  36. > >models directly, the same way we now create efficient programs in
  37. > >high-level languages and rely on optimizing compilers for efficiency.
  38. > 
  39. > Yeah...sure...to some extent, how we go from the graphic design to
  40. > the working software is irrelavent except that, as we improve on
  41. > a step-by-step basis, we will generate various levels of intermediate
  42. > code first...even today, many C/C++ compilers generate intermediate
  43. > assembler code...and we are somewhat constrained by the current
  44. > linker conventions...
  45.  
  46. Agreed.  But my point is that we ought to be ignoring the middle code
  47. layer.  If we happen to generate C++/Java/Eiffel/... that's fine.  But
  48. we ought to think of system analysis/design/implementation at the model
  49. level, and bring up the executable specification to that level.  I suppose
  50. you might care about the code layer if you're working on optimization, but
  51. like Knuth pointed out many years ago, the first rule of optimization is
  52. "DON'T!"  (It's rarely needed.)  Bottom line: 3GL code generation ought
  53. to be invisible to the same extent assembly-code generation is today.
  54.  
  55. > >"Unifying Modeling and Programming through an Active, Object-Oriented,
  56. > >Model-Equivalent Programming Language,"  S.W. Liddle, D.W. Embley, and
  57. > >S.N. Woodfield, Lecture Notes in Computer Science, no. 1021, pp. 55-64,
  58. > >Springer-Verlag, Berlin, 1995.
  59. > 
  60. > Any chance it's available on-line?
  61.  
  62. Copyright issues here. :(  I can e-mail you an earlier working-paper
  63. version of it if you'd like (e-mail me if you want a copy).  We're
  64. also putting together an expanded version for a chapter in an upcoming
  65. book on OO data modeling.
  66.  
  67. Cheers!
  68.  
  69. Steve Liddle
  70. mailto:liddle@byu.edu
  71.